…Client from public interface

- Replace buildBearerAbility/buildSessionAbility with authenticateBearer/authenticateSession
- Add RbacEnvironment, RbacUser, BearerAuthResult, SessionAuthResult types
- Remove PrismaClient from @trigger.dev/plugins interface (no Prisma crossing repo boundary)
- Remove @trigger.dev/database dependency and api-extractor from plugins package
- Switch plugins build to tsup --dts, delete api-extractor.json and tsconfig.dts.json
- OSS fallback imports PrismaClient from @trigger.dev/database directly
- OSS loader passes helpers-only to enterprise plugin, (prisma, helpers) to fallback
- Add rbac.server.ts singleton to webapp
- PoC: migrate admin.concurrency route to rbac.authenticateSession + canSuper()

…wJWT option, buildJwtAbility

Adds a `forceFallback` option to the RBAC loader so tests (and any other
consumer that sets RBAC_FORCE_FALLBACK=1) pin authentication to the OSS
fallback regardless of whether the enterprise plugin is installed.

- internal-packages/rbac: LazyController and RoleBaseAccess.create now accept
  RbacCreateOptions.forceFallback. When true, load() skips the dynamic import
  of @triggerdotdev/plugins/rbac and constructs RoleBaseAccessFallback
  directly.
- apps/webapp env: new RBAC_FORCE_FALLBACK BoolEnv, threaded into
  app/services/rbac.server.ts.
- testcontainers webapp: set RBAC_FORCE_FALLBACK=1 so e2e tests exercise the
  fallback deterministically.
- api-auth.e2e.test.ts: covers the fallback wiring end-to-end via the existing
  /admin/concurrency route, which already uses rbac.authenticateSession +
  ability.canSuper().

Close the coverage gap identified in the TRI-8716 audit before TRI-8719
swaps apiBuilder.server.ts to rbac.authenticateBearer. All new tests run
against the legacy authenticateApiRequestWithFailure /
authenticateApiRequestWithPersonalAccessToken path and must stay green
after the migration.

- Action requests (createActionApiRoute) via POST /api/v1/idempotencyKeys/:key/reset:
  * Valid private API key → passes auth (400 on zod body validation, not 401/403).
  * Missing Authorization → 401.
  * Invalid API key → 401.
- JWT on the same action route (allowJWT: true, superScopes write:runs, admin):
  * JWT with matching scope → passes auth.
  * JWT with read-only scope → 403.
- Personal access tokens (createLoaderPATApiRoute) via GET /api/v1/projects/:ref/runs:
  * Missing Authorization → 401.
  * API key (tr_dev_*) on PAT-only route → 401.
  * Wrong-prefix or malformed PAT → 401.
  * Well-formed but unknown PAT → 401.
  * Revoked PAT → 401.
  * Valid PAT on unknown project → 404 (auth passes).
- Edge case: valid API key whose project.deletedAt is set → 401.

Also fix the TRI-8715 redirect assertion: the webapp sends clients to
/login?redirectTo=... so compare by pathname rather than exact string.

New helper test/helpers/seedTestPAT.ts seeds a User + PersonalAccessToken
row using the same hashing/encryption scheme the webapp uses (shared
test ENCRYPTION_KEY), so the webapp subprocess can authenticate against
the seeded token.

otu and realtime.skipColumns propagation are deferred: they're only
observable via real trigger / realtime-stream flows, which need
workers/streams enabled and are out of scope for a coverage PR. The
migration preserves those fields via BearerAuthResult.jwt; dedicated
coverage can ride with TRI-8719 if needed.

Close the resource-scoped JWT coverage gap before TRI-8719 swaps
apiBuilder to rbac.authenticateBearer. Target:
POST /api/v1/waitpoints/tokens/:waitpointFriendlyId/complete — allowJWT,
resource: { waitpoints: params.waitpointFriendlyId }, superScopes:
[write:waitpoints, admin].

New helper test/helpers/seedTestWaitpoint.ts seeds a Waitpoint in
COMPLETED status so the handler short-circuits once auth passes, keeping
the 200 assertion independent of run-engine workers.

7 new tests exercise the legacy checkAuthorization scope algebra that
the migration must preserve:

- scope matches exact resource id → 200
- scope targets a different id of the same type → 403
- type-level scope (no id) grants all resources of that type → 200
- read-only scope on a write route → 403
- scope targets a different resource type → 403
- admin super-scope → 200 (legacy super-scope listing)
- unrelated type scope with no super-scope match → 403

Without these, the only JWT coverage was coarse type-level allow/deny
against routes whose resource callbacks returned () => 1 or () => ({}),
leaving resource-id matching entirely untested end-to-end.

Lock in the legacy checkAuthorization behaviours that TRI-8719 must
preserve once it swaps in rbac.authenticateBearer + ability.can.

Three tests in a new describe block 'JWT bearer auth — behaviours to
preserve through TRI-8719':

- Custom action route: type-level write:tasks JWT on
  POST /api/v1/tasks/:taskId/trigger (action: trigger) → auth passes
  today via exact superScope match. Must keep passing after TRI-8719
  via the ACTION_ALIASES map (trigger ← write).
- Multi-key resource: read:tags:<tag> JWT on /api/v1/runs/:runId/trace
  where the seeded run has that tag → auth passes today because
  legacy checks each resource key. Must keep passing after TRI-8719
  via ability.can's array-resource form.
- Multi-key resource: read:batch:<friendlyId> JWT on
  /api/v1/runs/:runId/trace where the seeded run is in that batch →
  same rationale as the tags case.

Dropped the planned empty-resource test: researching it surfaced that
legacy checkAuthorization denies empty-resource requests BEFORE the
super-scope check runs, so api.v1.batches.ts and idempotencyKeys reset
currently reject all JWTs despite allowJWT: true. TRI-8719's plan
(adding explicit { type: 'runs' }) is an intentional improvement, not
a preservation — documented in the TRI-8719 description comment.

New helper test/helpers/seedTestRun.ts seeds a minimal TaskRun (and,
optionally, an associated BatchTaskRun) that ApiRetrieveRunPresenter's
findRun can resolve for multi-key resource tests. The tests only
assert 'auth passes' (!== 401, !== 403) — the handler's downstream
behaviour (which may fail in a worker-less test env) isn't relevant
to the auth-layer contract.

Foundational changes before swapping apiBuilder to rbac.authenticateBearer.
No behaviour change yet — apiBuilder is still on the legacy path.

Array resources:
- @trigger.dev/plugins RbacAbility.can now accepts RbacResource | RbacResource[].
  Array form means 'grant access if any element passes', preserving the
  legacy checkAuthorization multi-key semantic once TRI-8719 completes.
- internal-packages/rbac ability.ts: permissive/super/deny pass through
  unchanged; buildJwtAbility iterates the array and short-circuits on
  first match.

Action alias wrapper (internal-packages/rbac/src/index.ts):
- ACTION_ALIASES map + withActionAliases function. Wraps an underlying
  RbacAbility so that can(action, resource) retries with alias actions
  when the direct check fails. Currently: trigger, batchTrigger, update
  are all satisfied by a scope whose action is write — matching legacy
  superScope behaviour for route.action values that don't align with
  scope prefixes.
- LazyController wraps the ability it gets from authenticateBearer /
  authenticateSession. authenticateAuthorize* stop delegating to the
  underlying's own Authorize methods (that would bypass the wrapper)
  and instead do the inline ability.can check against the wrapped
  ability.

The enterprise plugin (TRI-8720) does not need to know about aliases —
the wrapper applies uniformly regardless of which ability came back.

Tests:
- ability.test.ts: +4 tests for array resource form (31 total in file).
- loader.test.ts: +11 tests for withActionAliases (direct match, alias
  retry for trigger/batchTrigger/update, id-scoped retry, admin passes,
  array form retry, canSuper delegation).
- Unit suite: 31 tests, all passing.
- Webapp typecheck: clean.

…I-8719 Phase B)

Swap all three apiBuilder call sites (loader, action, multi-method) from
authenticateApiRequestWithFailure + checkAuthorization to a single RBAC
plugin bridge. 30 route files migrated in lockstep — drop the
authorization.superScopes option, convert resource callbacks to return
RbacResource or RbacResource[] in the new shape.

Infrastructure:

- apiBuilder: new authenticateRequestForApiBuilder helper funnels all
  three builders through rbac.authenticateBearer and follow-up
  findEnvironmentById to rebuild the legacy ApiAuthenticationResultSuccess
  shape handlers still expect (no handler-facing changes).
- @internal/rbac: re-export RbacAbility, RbacResource from
  @trigger.dev/plugins so webapp only depends on @trigger.dev/rbac.

Route-file changes (Risk mitigations from the ticket):

- Custom actions (trigger, batchTrigger, update) unchanged at the route
  level — the ACTION_ALIASES wrapper from Phase A handles them
  transparently.
- Multi-key runs routes (api.v3.runs.$runId, realtime.v1.runs.$runId,
  realtime.v1.streams.$runId.$streamId, api.v1.runs.$runId.events /
  .spans.$spanId / .trace, realtime.v1.streams.$runId.input.$streamId
  second block, plus the batch-array routes) now return
  RbacResource[] — any resource match grants access. Undefined batch
  ids are filtered out to avoid accidentally matching a type-level
  read:batch scope with no id.
- Empty-resource routes (api.v1.batches, api.v1.idempotencyKeys.$key.reset)
  now return { type: 'runs' } — JWTs with read:runs / write:runs start
  working where they were previously denied by the legacy
  empty-resource short-circuit. Intentional improvement, strict
  superset of today's accept set.
- Search-params routes (realtime.v1.runs, api.v1.runs) return an array
  with a collection-level { type: 'runs' } plus any filtered tag/task
  entries so JWTs that work today continue to work.

Verification:

- pnpm run typecheck --filter webapp: clean.
- pnpm run test --filter @internal/rbac: 31 unit tests pass (wrapper +
  array-resource semantics).
- E2E suite (test/api-auth.e2e.test.ts): all 31 tests pass on the new
  code path — the three pre-migration 'behaviours to preserve' tests
  (type-level write:tasks triggers a task, read:tags:<tag> reaches a
  run with that tag, read:batch:<id> reaches a run in that batch) are
  still green post-swap.

Packaging:

- .changeset/rbac-plugin-array-resources.md: minor bump for
  @trigger.dev/plugins (array-resource overload on RbacAbility.can).
- .server-changes/rbac-apibuilder-migration.md: webapp-only note.

Add a session-auth route builder analogous to apiBuilder.server.ts that
routes dashboard auth through rbac.authenticateSession and runs the
ability check (canSuper or can) before the handler runs. Routes that
only need a logged-in user (no authorisation) keep using requireUser /
requireUserId — the builder is opt-in for routes with explicit auth.

Builder shape:

  dashboardLoader({ authorization: { requireSuper: true } }, async ({ user, ability }) => ...)
  dashboardLoader({ authorization: { action, resource } }, ...)
  dashboardAction(...)

Auth failure throws a redirect Response so the success-path return type
stays narrow (useTypedLoaderData<typeof loader>() picks up the handler's
TypedJsonResponse). Optional context callback feeds organizationId /
projectId to authenticateSession when needed (enterprise-only — fallback
ignores context today).

Migrated 14 platform admin routes from
`requireUser` + `if (!user.admin)` to dashboardLoader / dashboardAction
with requireSuper: true:

  admin.tsx
  admin._index.tsx
  admin.concurrency.tsx
  admin.feature-flags.tsx
  admin.notifications.tsx
  admin.orgs.tsx
  admin.data-stores.tsx
  admin.back-office.tsx
  admin.back-office._index.tsx
  admin.back-office.orgs.$orgId.tsx
  admin.llm-models._index.tsx
  admin.llm-models.$modelId.tsx
  admin.llm-models.new.tsx
  admin.llm-models.missing._index.tsx
  admin.llm-models.missing.$model.tsx

Routes that have admin-only sub-features (e.g. show-extra-fields-if-admin
on otherwise public routes) stay on requireUser. Migration of those is a
separate concern — they don't gate access on admin, they just branch
display.

Behavioural change: action handlers that previously threw
`new Response('Unauthorized', { status: 403 })` on non-admins now redirect
to / along with the loader. Uniform behaviour, but XHR fetchers that
expected a 403 status would now follow the redirect instead. The admin
pages migrated here don't appear to have XHR fetchers that depend on the
403, but worth flagging.

Verification:
- pnpm run typecheck --filter webapp: clean.
- pnpm run test --filter @internal/rbac: 31 unit tests pass.
- E2E suite: all 31 tests pass — including the
  /admin/concurrency redirect test (now exercising the new builder).

Widen check.resource on the convenience methods to RbacResource |
RbacResource[] so they match RbacAbility.can. Previously the interface
declared only RbacResource on these methods, which left an
inconsistency — anyone wanting to pass an array of resources had to
call authenticateBearer + ability.can manually instead of using the
convenience method.

Surfaced when reviewing the cloud enterprise controller (TRI-8720),
which had unilaterally widened its implementation to RbacResource[]
and would have failed type-check if any caller routed an array
through the typed interface.

Updated:

- packages/plugins/src/rbac.ts — RoleBaseAccessController interface.
- internal-packages/rbac/src/fallback.ts — RoleBaseAccessFallback
  matches.
- LazyController already uses Parameters<...> and tracks the
  interface, so it picks up the change automatically.

@trigger.dev/plugins gets a minor bump (changeset added).

Verification:

- pnpm run typecheck across @trigger.dev/plugins, @trigger.dev/rbac,
  webapp — clean.
- pnpm run test --filter @internal/rbac — 31 unit tests pass.
- e2e suite unaffected (no signature change at runtime — pure type
  widening).

…suite (TRI-8732)

Foundation for TRI-8731. The smoke api-auth.e2e.test.ts spins up its own
webapp + Postgres container per test file (~30s startup each). The
comprehensive matrix would have 12+ files, so per-file startup would
dominate runtime. Instead this harness boots one container for the whole
suite and rapid-fires tests across multiple files.

Layout:

- vitest.e2e.full.config.ts — globalSetup + pool: forks. Picks up
  test/**/*.e2e.full.test.ts.
- test/setup/global-e2e-full-setup.ts — calls startTestServer() once,
  provides baseUrl + databaseUrl to test workers via vitest's
  provide()/inject() API. Tears down on suite end.
- test/helpers/sharedTestServer.ts — getTestServer() pulls the provided
  values, constructs a per-worker PrismaClient, exposes
  { webapp, prisma } matching the existing TestServer shape.
- test/helpers/seedTestSession.ts — produces a Cookie header value
  compatible with the webapp's createCookieSessionStorage config so
  dashboard tests (TRI-8742) can authenticate as a seeded user.
- test/auth-api.e2e.full.test.ts, test/auth-dashboard.e2e.full.test.ts,
  test/auth-cross-cutting.e2e.full.test.ts — three file shells with
  top-level describe blocks. Family subtasks (TRI-8733+) add nested
  describes inside.
- .github/workflows/e2e-webapp-auth-full.yml — workflow_dispatch +
  nightly schedule + pull_request paths-filtered (only triggers on PRs
  touching auth-relevant files).
- test/README.md — documents the unit / smoke-e2e / full-e2e split.

Touching @internal/testcontainers:

- TestServer interface gains databaseUrl so per-worker PrismaClient
  reconstruction has the connection string without going through the
  serialised prisma instance (which can't cross worker boundaries).
- utils.ts — assertNonNullable's vitest import was previously eager at
  module load. globalSetup runs outside any vitest worker, so that
  eager init crashed (createExpect needs worker state). Switched to a
  lazy require('vitest') inside the function body. The function still
  runs in test workers where worker state exists.
- logs.ts — TaskContext changed to type-only import for the same
  module-load-time concern (transitively imported by webapp.ts).

Verification:

- pnpm run typecheck across @internal/testcontainers + webapp — clean.
- pnpm exec vitest run --config vitest.e2e.full.config.ts —
  3/3 tests pass in 19.37s with one observed container startup.
  Subsequent family subtasks add describes with no per-file container
  cost.

The placeholder it() in each file (just hits /healthcheck or counts
users) gets removed by the family subtasks as they add real coverage.

Mutation methods on RoleBaseAccessController now return discriminated
Result unions instead of throwing on expected error paths:

- RoleMutationResult — { ok: true; role: Role } | { ok: false; error }
  for createRole, updateRole.
- RoleAssignmentResult — { ok: true } | { ok: false; error: string }
  for deleteRole, setUserRole, removeUserRole, setTokenRole,
  removeTokenRole.

The cloud webapp surfaces the 'error' strings directly to users
(system role edits, plan-tier gating, validation conflicts), so a
thrown exception now signals only an unexpected failure (DB outage,
bug). Read methods (getUserRole, getTokenRole, allRoles,
allPermissions) are unchanged.

OSS fallback returns { ok: false, error: 'RBAC plugin not installed' }
for every mutation — matches the prior behaviour (createRole/updateRole
already threw with this message; the others were silent no-ops, which
made misuse hard to detect). The LazyController in @internal/rbac
forwards the new return types verbatim. Changeset: patch.

Customer-facing surface: only public type widening of mutation method
return types — no runtime behaviour change for OSS callers (they get
a Result error instead of a thrown error or silent no-op; both indicate
'do not call these without the enterprise plugin').

The dev build was crashing with 'dashboardLoader is not a function'
on first navigation to any /admin route, then the browser would
hard-reload back to the previous page. Symptom: clicking 'Admin
dashboard' (or anywhere /@ → /admin chain) flashed admin then bounced
back, with no obvious cause server-side (every loader returned 200).

Root cause: routes export their loader at module top-level via the
wrapper:
    export const loader = dashboardLoader(...);
The factory call evaluates at module load. dashboardBuilder lived in
a .server.ts file, which Remix strips from the client bundle. In the
prod build the loader export + its RHS are both tree-shaken, so the
import is unreferenced and removed — fine. In the dev build the call
is preserved (HMR/source-map friendliness) and resolves
dashboardLoader to undefined on the client, throwing on module load.
Remix's recovery is to reload the page, which lands on the previous
URL because that's the last known-good navigation entry.

Fix: split the wrapper so the import target exists on both server
and client.
- dashboardBuilder.ts (no .server) — exports types + dashboardLoader /
  dashboardAction wrappers. Wrappers return closures whose bodies
  dynamic-import the server impl. The closure body never runs on the
  client, so the dynamic import only resolves at server runtime.
  Client just sees a function that returns another function — the
  top-level call now works there.
- dashboardBuilder.server.ts — slimmed down to authenticateAndAuthorize
  + the redirect/authorization helpers. Imported via dynamic import
  from the wrapper. Stays out of the client bundle.

Routes drop the .server suffix on the import path. No change to the
route's loader/action surface. Verified end-to-end via Chrome
DevTools: /@ → /admin chain renders the admin dashboard cleanly,
no console errors, no extra document fetch back to the org URL.

…ting (TRI-8748)

Wire RBAC into the existing org Teams page (settings/team).

OSS plugin
- Adds RoleBaseAccessController.getAssignableRoleIds(orgId) — the
  subset of allRoles(orgId) that can be assigned right now. Returns
  [] in the OSS fallback (consistent with allRoles also returning []
  there). Pure UI affordance: server-side enforcement remains
  setUserRole's lookupAssignableRole. Public package change with
  patch-level changeset.

Enterprise plugin
- Implements getAssignableRoleIds against PlansClient: system roles
  pass through isSystemRoleAssignable (Owner/Admin always; Member /
  Viewer require Pro+); custom roles require canCreateCustomRoles
  (Enterprise tier). Mirrors the gates in setUserRole so UI and
  server agree.

Webapp
- TeamPresenter now also returns rbac.allRoles(orgId),
  getAssignableRoleIds(orgId), and per-member role assignments.
  Per-member is N+1 today (low-traffic settings page); a batched
  lookup is filed as a future optimisation.
- Route migrated from requireUserId to dashboardLoader / dashboardAction
  via the split builder (commit a2cdbfb). Loader gates on
  read:members; action stays permissive at the wrapper level so the
  existing remove/leave + purchase-seats flows keep working with
  their per-intent checks. New set-role intent gates on
  manage:members and calls rbac.setUserRole — surfaces the Result
  error inline next to the dropdown when the server rejects (system
  role rename, plan-gated assignment, foreign-org role).
- UI: native select next to each member, defaults to that member's
  current role. Options not in assignableRoleIds render disabled
  with an (upgrade) suffix. Auto-submits on change via fetcher.
  Invite + Remove buttons hide/disable when canManageMembers is
  false (server-side ability check pre-computed in the loader).
  Self-leave is always allowed regardless of manage:members.

Verification
- Typecheck clean across @internal/rbac, webapp, enterprise/plugins,
  enterprise/db, packages/plans.
- Browser smoke test deferred until webapp dev server is running.

Pairs with the enterprise/db backfill migration (cloud side) so every
new (user, org) pair gets a UserRole row from day one without anyone
falling through to PERMISSIVE_ABILITY on the Teams page.

Mapping mirrors the backfill (legacy ADMIN had full access; the new
Admin role excludes billing + member management, so legacy ADMIN
belongs in the new Owner slot, not the new Admin slot):

  legacy ADMIN  -> Owner  (sys_role_owner)
  legacy MEMBER -> Member (sys_role_member)

Changes:

- services/rbac.server.ts: export SYSTEM_ROLE_IDS constant. The IDs
  are seeded by the enterprise/db migration and never change; both
  org creation and invite acceptance import from here so the role
  reference is in one place.
- models/organization.server.ts: createOrganization calls
  rbac.setUserRole({ roleId: owner }) after the org row is created.
  Outside any transaction (rbac uses a separate Drizzle/postgres-js
  connection). On OSS the fallback returns ok=false; we log + continue
  since the legacy OrgMember.role write is the source of truth there.
- models/member.server.ts: acceptInvite assigns Owner if the invite
  was ADMIN (defensive — the current UI only invites with MEMBER) or
  Member otherwise. setUserRole runs after the prisma transaction
  commits for the same reason as above. Returns the same shape as
  before so callers don't change.

Verification: typecheck clean. Migration step (TRI-8854 part 1) is on
the cloud side; together they ensure both existing and new (user, org)
pairs land on a sensible RBAC role.

Lets users pick a system role at PAT-create time and persists it via
enterprise.TokenRole so PAT-authenticated requests will run with that
role's permissions once the auth-side wiring lands.

V1 scope decisions (worth flagging for review):

1. System roles only. PATs are user-scoped (not org-scoped) and
   custom roles are per-org — the role-to-org mapping for a multi-org
   user's PAT is a non-trivial design question that doesn't need to
   be answered for v1. Show the four seeded system roles
   (Owner/Admin/Member/Viewer); a follow-up can add custom roles
   once we've decided what "this PAT uses an org X custom role"
   means semantically.

2. Default to caller's own role. Loader queries rbac.getUserRole
   against the user's first org membership (createdAt ASC) and uses
   that as the dropdown default — a PAT can't be more privileged
   than the person creating it without an explicit upgrade. Falls
   back to Member for users with no role assignment yet (OSS or new
   user pre-backfill).

3. No plan gating. Plan tiers are per-org; PAT roles are global.
   Plan gating only made sense in the org-scoped Teams page UI
   (TRI-8748).

4. No privilege-escalation check. Today's PATs run through the
   legacy auth path with full superScopes — even a "Owner" PAT here
   is strictly less permissive than the status quo. Locking down
   "the PAT can't exceed the creator's role" is a hardening for a
   later ticket once the read-side actually keys off TokenRole.

Changes:

- services/personalAccessToken.server.ts: createPersonalAccessToken
  takes an optional roleId. When provided, calls rbac.setTokenRole
  after the Prisma PAT row is created. On a real failure the PAT is
  compensating-deleted (the two writes live on different ORMs sharing
  one connection — co-transactions are awkward, compensating delete
  is simpler). The OSS fallback's "RBAC plugin not installed" return
  is treated as success-with-no-role: the PAT row stays, just no
  TokenRole gets written, matching pre-RBAC behaviour.
- routes/account.tokens/route.tsx: loader fetches system roles +
  caller's current role; create form shows a role <Select> with the
  caller's role as default; OSS path (allRoles returns []) hides the
  dropdown entirely. Action passes roleId through to the service.

Out of scope here (covered elsewhere):

- The PAT auth-side path that will JOIN TokenRole and build an ability
  from the role's permissions. Lives in the enterprise plugin's
  authenticatePat path; tracked under the TRI-8741 test surface and
  the broader auth-consolidation work in TRI-8744.
- CLI auth-code PAT (createPersonalAccessTokenFromAuthorizationCode)
  unchanged. CLI PATs continue to be created without an explicit
  role — they go through the legacy permissive path and existing
  user expectations of "trigger dev just works" are preserved.

Verification: typecheck clean on webapp. Browser smoke test deferred
to your local run.

Per-batch endpoints share a single-id resource config:
  resource: { type: "batch", id: batch.friendlyId }

Notable: the resource type is "batch", NOT "runs". The legacy
literal-match escape that let read:runs JWTs hit batch endpoints
no longer applies post-TRI-8719. Tests pin this down.

The list endpoint (GET /api/v1/batches) was deleted on the s3-
switchover branch — list-section coverage is N/A on this branch.
If/when the list endpoint returns, add a list-side describe.

api.v1.batches.$batchId — 10 cases:
  - missing auth → 401
  - invalid API key → 401
  - private API key on real batch → auth passes
  - JWT read:batch:<friendlyId> matching → passes
  - JWT read:batch:<other> → 403
  - JWT read:batch (type-level) → passes
  - JWT read:runs → 403 (resource type is "batch", not "runs"
    — pre-TRI-8719 this passed via legacy literal-match escape;
    locking in the post-migration strict behaviour)
  - JWT read:all → passes
  - JWT admin → passes
  - cross-env: env A's JWT cannot read env B's batch → not 200

api.v2.batches.$batchId — 2-case sanity (config identical to v1).
realtime.v1.batches.$batchId — 2-case sanity.

If a route in this family ever diverges from the canonical pattern,
add a dedicated describe.

Reuses seedTestRun({ withBatch: true }) — helper already creates
the BatchTaskRun + linked TaskRun for us.

Verification: typecheck clean. Test execution still blocked by the
e2e.full webapp-boot issue noted on TRI-8731.

Prompts route family — read + update actions, both single-id
({type:"prompts", id: params.slug}) and collection-level
({type:"prompts", id: "all"}) resource shapes.

Auth resolves before any DB lookup, so tests use non-existent
slugs throughout; handler 404s but auth-passed assertion
("not 401, not 403") is what the matrix verifies.

Coverage:

Prompts list — GET /api/v1/prompts (5 cases):
  - missing auth → 401
  - private API key → auth passes
  - JWT read:prompts → passes
  - JWT read:runs → 403 (type mismatch)
  - JWT admin → passes

Prompts retrieve — GET /api/v1/prompts/:slug (7 cases, full matrix):
  - missing auth → 401
  - private API key → passes
  - JWT read:prompts → passes
  - JWT read:prompts:<exact slug> → passes
  - JWT read:prompts:<other> → 403
  - JWT read:runs → 403 (type mismatch)
  - JWT admin → passes

Prompts override — POST /api/v1/prompts/:slug/override (6 cases):
  Tests the ACTION_ALIASES write→update behaviour:
  - missing auth → 401
  - JWT write:prompts:<slug> matching → passes
  - JWT write:prompts (type-level) → passes
  - JWT read:prompts → 403 (action mismatch — read NOT aliased)
  - JWT write:prompts:<other> → 403
  - JWT admin → passes

Promote/reactivate sanity (2 cases):
  - promote: JWT write:prompts → passes
  - reactivate: JWT read:prompts → 403

Multi-method override (POST/PUT/PATCH/DELETE) is not exhaustively
tested per-method — they share the same authorization config so
covering POST suffices. If a method ever overrides authorization,
add a targeted test.

Verification: typecheck clean. Test execution still blocked by the
e2e.full webapp-boot issue noted on TRI-8731.

Read-only family with distinct resource types per route:
  - GET /api/v1/deployments       { type: "deployments", id: "list" }
  - GET /api/v1/query/schema      { type: "query", id: "schema" }
  - GET /api/v1/query/dashboards  { type: "query", id: "dashboards" }
  - POST /api/v1/query            body-derived via detectTables(query)
                                  → tables.length > 0
                                    ? tables.map(id => ({type:"query", id}))
                                    : { type: "query", id: "all" }

Coverage:

Deployments list (7 cases):
  - missing auth → 401
  - private API key → passes
  - JWT read:deployments → passes
  - JWT read:all → passes
  - JWT admin → passes
  - JWT read:runs → 403 (type mismatch)
  - JWT write:deployments → 403 (action mismatch)

Query schema sanity (3 cases):
  - missing auth → 401
  - JWT read:query → passes
  - JWT read:deployments → 403 (type mismatch)

Query dashboards sanity (2 cases):
  - missing auth → 401
  - JWT read:query → passes

Query ad-hoc body-derived (6 cases):
  - missing auth → 401
  - body "SELECT * FROM runs" + JWT read:query:runs → passes
    (any-match against the body-derived array)
  - body "SELECT 1" (no detectable tables) + JWT read:query → passes
    (defaults to id="all"; type-level scope matches)
  - body with 'runs' + JWT read:query:other_table → 403
  - JWT admin → passes regardless of body
  - JWT write:query → 403 (action mismatch)

Verification: typecheck clean. Test execution still blocked by the
e2e.full webapp-boot issue noted on TRI-8731.

This closes the TRI-8731 test family (8733, 8734, 8735, 8736, 8737,
8738, 8739, 8740, 8741, 8742, 8743 — all done across today's
commits).

The e2e.full harness was failing to boot the webapp testcontainer
with `TypeError: Cannot convert undefined or null to object at
allMachines (build/index.js:71583)`. Root cause: the testcontainer
was setting NODE_ENV=test, which surfaces a circular-init order
regression in the production bundle that NODE_ENV=production
dodges (modules init in a different order under prod-mode and the
relevant singleton resolves before the cycle re-enters). Production
builds work fine — the harness just needs to match prod-mode boot.

Single one-line change in testcontainers: NODE_ENV is now
"production" instead of "test". Tests don't depend on test-mode
semantics — they just need an isolated webapp + DB.

After unblocking, fixed 11 tests whose strict 2xx assertions were
correct against a request-time-resolved handler but wrong against
the test container (where ClickHouse and external services are
dummy URLs):

- 8 tests on api.v1.runs and api.v1.projects/<ref>/runs (PAT route):
  the run-list presenter hits ClickHouse which 500s in tests. Auth
  passes; assertion changed from strict 200 to "not 401/403".
- 2 tests on api.v1.prompts/:slug (retrieve): the apiBuilder runs
  findResource BEFORE authorization. With no Prompt fixture seeded
  the route 404s before the auth check, so a non-matching scope
  appears as 404 rather than 403. Both states mean "user can't see"
  — assertion changed to "not 200" with a comment explaining the
  ordering.
- 1 test on prompts /override/reactivate: route's BodySchema requires
  `{ version: positive int }`. My empty body 400'd at validation
  before auth. Sending `{ version: 1 }` lets validation pass and
  the auth check fires; gets the expected 403.

Plus 1 fixture fix on auth-cross-cutting.e2e.full.test.ts: the
TaskRun.create call needed `queue: "task/test-task"` (matches the
seedTestRun helper).

Verification:
  pnpm exec vitest run --config vitest.e2e.full.config.ts
  → 3 files, 162 tests, all pass. ~14 seconds.

…859)

Replace the hardcoded `RBAC_FORCE_FALLBACK: "1"` env var with an
optional `forceRbacFallback` parameter on `startWebapp` and
`startTestServer`. Default `true` preserves OSS suite behaviour
(every existing call site keeps fallback-pinned semantics).

Cloud's enterprise variant of the e2e suite passes `false` so the
spawned webapp loads the real `@triggerdotdev/plugins/rbac` instead
of the OSS fallback. Same harness, different RBAC implementation
under test.

Verification: OSS e2e.full suite still 162/162 passes.

…(TRI-8731)

After rebasing rbac-packages on origin/main, the e2e.full harness
regressed with the same `TypeError: Cannot convert undefined or null
to object at allMachines (build/index.js:71862)` that TRI-8731
worked around by switching the testcontainer to NODE_ENV=production.
Recent main commits changed the bundled init order enough that the
production-mode dodge no longer applies — the cycle now triggers in
both NODE_ENV=test and NODE_ENV=production.

Root cause is structural:

  app/services/platform.v3.server  →  imports createEnvironment
                                      from app/models/organization.server
  app/models/organization.server   →  imports getDefaultEnvironmentConcurrencyLimit
                                      from app/services/platform.v3.server

Inside an esbuild __esm bundle, this manifests as:

  init_platform_v3_server() runs init_organization_server() in the
  middle of its body. organization.server's body re-enters
  init_platform_v3_server(), which short-circuits because the outer
  call already cleared its `fn` — so `({ defaultMachine, machines } =
  singleton("machinePresets", ...))` never completes its destructure
  and both vars stay undefined. Object.entries(undefined) crashes
  when `allMachines()` runs inside `createRunEngine()`.

Fix: move the only function in platform.v3.server.ts that imports
from organization.server (`projectCreated`, the sole caller of
`createEnvironment`) into its own file. platform.v3.server.ts no
longer imports from organization.server, so the cycle is gone. Two
trivial supporting changes:

  - export `isCloud` from platform.v3.server (projectCreated needs it)
  - drop the now-unused `Organization` and `Project` type imports

No dynamic imports, no application-code workarounds — just a
structural file split.

Verified:
  - 162/162 e2e.full pass (auth-api, auth-cross-cutting, auth-dashboard)
  - 31/31 api-auth.e2e pass
  - 31/31 @trigger.dev/rbac unit tests pass
  - 7/7 cloud enterprise e2e.full pass against the same webapp build

Adds a Settings → Roles page that lists every role visible to the org,
with each role's permissions rendered in a Table grouped by category
(Runs, Tasks, Waitpoints, Realtime, Deployments, Prompts, Query,
Tokens, Organisation, Wildcards). Each permission shows its name and
description.

Page surfaces:
  - Role name + description + System/Custom badge
  - "Not on this plan" badge for roles outside the current plan tier
    (system roles gated by PlansClient.isSystemRoleAssignable)
  - "Create role" button:
      - Free / Hobby / Pro: opens an "Upgrade to Enterprise" dialog
        with a Contact us CTA (deep-links to trigger.dev/contact)
      - Enterprise: hidden — the create-role UI is a follow-up after
        TRI-8747's controller-level CRUD already in place

Plumbing:
  - apps/webapp/app/routes/_app.orgs.$organizationSlug.settings.roles
  - organizationRolesPath helper in pathBuilder
  - Roles SideMenuItem next to Team in OrganizationSettingsSideMenu
  - "View all role permissions →" link on the Teams page next to the
    Active team members section so an Owner about to assign a role can
    audit the choice

The enterprise plugin's getUserRole now derives a user's role from the
legacy public.OrgMember.role column whenever no explicit UserRole row
exists (separate cloud commit). That makes the upfront UserRole writes
in createOrganization and acceptInvite redundant — the role display
and ability checks both work from day one based on OrgMember alone.

Removed:
  - The rbac.setUserRole call + SYSTEM_ROLE_IDS import from
    apps/webapp/app/models/organization.server.ts (createOrganization)
  - The rbac.setUserRole call + SYSTEM_ROLE_IDS import from
    apps/webapp/app/models/member.server.ts (acceptInvite)

A UserRole row is now only ever inserted when an Owner explicitly
changes someone's role on the Teams page. Everyone else's role is
derived live from OrgMember.role.

Code comments throughout the OSS-facing RBAC surface mentioned the
enterprise plugin, CASL, the cloud webapp, the cloud-side test suite,
and specific cloud file paths. Two reasons not to keep that:

  - Reputation: comments framing the OSS code as "the OSS path" vs
    "the enterprise path" pollute the public repo with implementation
    framing that shouldn't be there.
  - Implementation leakage: enterprise/cloud comments give away
    structural details about the closed-source plugin (where its data
    lives, what library it uses, which Linear tickets track it).

Rewrites use neutral language — "the loaded RBAC plugin (if any)",
"the default fallback", "an installed plugin" — and drop references
to specific cloud-side files / TRI-IDs / CASL.

Plan-tier names ("Enterprise" as a public product tier in the Roles
page upsell, `planCode === "enterprise"` checks, `<TierEnterprise />`
in pre-existing files) are intentionally left as-is — they're the
public marketing name for a paid tier, not implementation detail.

Removed `.server-changes/rbac-userrole-default-assignment.md` —
documented a feature that was reverted in d2bf617 (upfront UserRole
inserts on create-org / acceptInvite).

Verified: 162/162 OSS e2e.full pass, 31/31 OSS rbac unit pass.

…ge note

Pairs with the cloud-side change that removes `admin`, `read:all`,
and `write:all` from PERMISSION_CATALOGUE. With no catalogue entry
sitting in the Wildcards group, the corresponding entries in the
client-side PERMISSION_GROUP_BY_NAME map are dead and the group is
removed from GROUP_ORDER.

…I-8893)

Pairs with the cloud-side CASL refactor that switches role storage to
packed CASL rules + introduces conditional rules (e.g. Member's prod
env-var restrictions). Two interface changes here:

  - Permission gains optional `inverted` and `conditions` fields. The
    Roles page renders `inverted: true` rules as ✗ and `conditions`
    (e.g. `{ envType: "PRODUCTION" }`) as a tier badge.

  - RbacResource gains an open-ended `[key: string]: unknown` index so
    routes can pass condition-relevant fields alongside `type` / `id`
    (e.g. `{ type: "envvars", envType: env.type }`). The plugin's
    CASL-backed matcher reads these off the resource object.

Roles page UI: TableHeader gains an "Allowed" column rendering ✓/✗
per rule, and conditional rules show a `(production only)` /
`(non-production only)` Badge next to the permission name. Group order
gains a leading "All" for Owner/Admin's wildcard rules and an
"Environment" group for the new envvars/apiKeys catalogue pairs.

…8904)

Replaces the per-role tables with a single comparison grid: rows are
catalogue permissions grouped by category (Runs, Tasks, Environment,
…), columns are Owner, Admin, Developer, Member, then any
custom roles, then Description. Each cell shows whether that role
grants the permission.

Cell rendering driven by `effectivePermissions(role.rules)` (TRI-8893):

  - No matching rules → ✗ in muted colour
  - Allow rule(s), no inverted → ✓ in success green
  - Allow rule(s) plus a conditional `cannot` → ✓ green + a tier badge
    rendered beneath ("non-prod only" for envType=PRODUCTION etc.)
  - Only inverted unconditional rule → ✗ in error colour

Plan tier hint in column headers — Developer / Member columns get a
small "Pro" Badge on Free/Hobby; custom roles get "Enterprise". Cells
still render the comparison data so users see what they'd unlock.

Loader extended to call `rbac.allPermissions(orgId)` so the catalogue
drives the row enumeration. Owner column ends up with ✓ on every row
(one rendered Permission per catalogue entry, expanded from the
`manage:all` packed rule via CASL's rulesFor walk).

Also: `SYSTEM_ROLE_IDS` updated from `{owner, admin, member, viewer}`
to `{owner, admin, developer, member}` — Viewer was dropped in TRI-8893
when the role ladder finalised; this catches up the OSS-side helper.
account.tokens uses `SYSTEM_ROLE_IDS.member` as the PAT default; the
new (more restricted) Member is the right default for that flow.

Adds a Role `<Select>` to the invite form. Dropdown options are
filtered by:

  1. The inviter's own role — strictly below their level (Owner can
     pick any of the 4; Admin can pick Developer or Member; Developer/
     Member don't see the picker because they can't invite anyway).
  2. The org's plan tier — `rbac.getAssignableRoleIds(orgId)` already
     reflects this (Free/Hobby = Owner+Admin only, Pro+ unlocks
     Developer+Member).

The picker is hidden entirely when `rbac.allRoles(orgId)` returns []
(OSS deployments with no plugin installed) — legacy invite path is
unchanged for self-hosters.

Schema: nullable `OrgMemberInvite.rbacRoleId text` column. On accept,
if it's set, `acceptInvite` calls the plugin's `setUserRole` after
the OrgMember insert (outside the Prisma transaction since the plugin
uses a separate Drizzle / postgres-js connection — same compensating
pattern as PAT-role assignment). If it's null, the runtime fallback
derives a role from the legacy `OrgMember.role` write at first
auth — no behaviour change.

Server-side validation in the action layer rejects:

  - rbacRoleId not in `getAssignableRoleIds(orgId)` (plan-tier check).
  - rbacRoleId at or above the inviter's own level (the
    canInviteAtRole ladder).

Legacy `OrgMemberInvite.role` enum (ADMIN/MEMBER) is still written
based on the chosen RBAC role — Owner/Admin → "ADMIN", Developer/
Member → "MEMBER" — so OSS auth keeps working.

Verified:
  - typecheck clean
  - 162/162 OSS e2e.full
  - 7/7 cloud enterprise e2e.full

Adds a new `systemRoleIds(): Promise<SystemRoleIds | null>` method on
the `RoleBaseAccessController` interface. Returns
`{ owner, admin, developer, member }` from any installed plugin and
`null` from the default fallback (matches the `allRoles → []`
semantics — there are no seeded roles to refer to in OSS).

Drops the `SYSTEM_ROLE_IDS` constant from `~/services/rbac.server` so
consumers can't reach for hardcoded role-id strings. Updates the four
sites that used it:

  - `models/member.server.ts` (invite flow's legacy-role mapping)
  - `routes/account.tokens` (PAT default)
  - `routes/_app.orgs.$organizationSlug.settings.roles` (Roles page
    comparison grid column ordering + plan-tier badges)
  - `routes/_app.orgs.$organizationSlug.invite` (role picker)

The Roles page and invite route both pass the IDs through their
loaders rather than referencing them at module top level — which was
the root cause of the "Invite a team member button hard-refreshes the
dashboard" bug: importing a `.server.ts` symbol from client-rendered
code left a dangling client-bundle reference.

Verified: typecheck clean, 162/162 OSS e2e.full, 7/7 cloud
enterprise e2e.full.

SelectLinkItem passes render={<Link>} so the row navigates on click. In
non-Combobox Selects (most use cases — the role picker on the Teams
page, etc.) SelectItem was overriding render to undefined, silently
dropping the Link wrapper. Pass props.render through verbatim when
there's no Combobox; wrap in ComboboxItem only when one's present.

The OSS no longer needs to know individual role names. systemRoles(orgId)
returns a plugin-owned, ordered SystemRole[] (id, name, description,
available) — the cloud plugin owns the canonical order, the descriptions,
and the per-org plan-tier 'available' flag. Hidden roles (Member in v1)
are filtered out entirely.

OSS callers iterate the array and use array index for the level ladder;
no role-name strings except for the legacy OrgMember.role enum mapping
shim, which is now isolated to one filter in member.server.ts.

…ker tightening

#1 Batch trigger AND semantics (security): `api.v[12].tasks.batch` now uses
`everyResource(...)` so a JWT scoped to taskA can no longer submit a batch
that also includes taskB / taskC. Added an `everyResource` helper to
`apiBuilder` (Symbol-marked wrapper that flips `ability.can` to `every`).
Multi-key OR semantics still apply for single-resource arrays (a run carries
multiple identifiers). Updated the e2e test to assert AND behaviour.

#3 Realtime stream resource (correctness): `findResource` for
`realtime.v1.streams.$runId.$streamId` now selects `taskIdentifier`,
`runTags`, and `realtimeStreamsVersion` — fields the auth resource
builder + handler read but findResource was returning undefined for.

#4 projectCreated optional chaining (crash bug): added the missing
`?.` between v3Subscription and plan so a missing subscription no longer
throws and aborts project creation.

#5 RBAC plugin loader logging: distinguish "plugin itself missing" from
"plugin found but a transitive dep failed to resolve" by inspecting the
ERR_MODULE_NOT_FOUND error message for the plugin's own module specifier.
The transitive-dep case now logs at error level (matches the comment's
stated behaviour). Removed the orphan log line that contradicted it.

#6 account.tokens picker source mismatch: the picker now sources roles
from the same plan-tier-filtered list (`systemRoles().filter(available)`)
as the default-role calculation. Added server-side roleId revalidation
in the create action so a hand-crafted POST can't bind a PAT to an
unavailable role.